Application-level acknowledgements

ABSTRACT

Application-level acknowledgements may be used to verify that a data packet has not only been received, but has been successfully processed by the appropriate application operating on a device that received the data packet. For example, in one embodiment, two devices may be registered with an identity service that enables security and push messaging. A first device may communicate a data packet to another device that is associated with the same identity account through the identity service. The device receiving the data packet may send an acknowledgement verifying receipt of the data packet. After an application has processed the data packet, an acknowledgement that the data packet was processed may also be send from the second device to the first device.

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application claims priority from and is a nonprovisionalapplication of U.S. Provisional Application 62/005,565 entitled“Application-Level Acknowledgements” by Pollack et al. (Ref. No.P23189USP1), filed May 30, 2014, the entire contents of which are hereinincorporated by reference for all purposes.

The present application is also related to U.S. ProvisionalApplications:

62/005,550 entitled “ANSWER AND HOLD WITH CLIENT AND HOST” byRauenbuehler et al. (Ref. No. P23172USP1), filed May 30, 2014;62/005,534, entitled “ANSWERING A CALL WITH CLIENT THROUGH A HOST” (Ref.No. P23171USP1), filed May 30, 2014;62/005,565 entitled “PROXIED PUSH” by Pollack et al. (Ref. No.P23053USP1), filed May 30, 2014;62/005,336 entitled “SMS PROXYING” by Circosta et al. (Ref. No.P23192USP1), filed May 30, 2014;62/005,505 entitled “MANAGING CONNECTIONS OF A USER DEVICE” by Schobelet al. (Ref. No. P23295USP1), filed May 30, 2014;62/005,606 entitled “CLIENT APPLICATIONS COMMUNICATING VIA A USERTUNNEL” by Tung et al. (Ref. No. P23188USP1), filed May 30, 2014;62/005,586 entitled “MESSAGES WITH ATTENUATING RETRANSMIT IMPORTANCE” byPollack et al. (Ref. No. P23190USP1), filed May 30, 2014; and62/005,799 entitled “PROTOCOL SWITCHING IN INTER-DEVICE COMMUNICATION”by Prats et al. (Ref. No. P22319USP1), filed May 30, 2014, which arehereby incorporated by reference for all purposes. The presentapplication is also related to U.S. Provisional Application61/953,591 entitled “DYNAMIC LINK ADAPTATION FOR IMPROVED LINK MARGIN,”by Liu et al., filed Mar. 14, 2014, which hereby incorporated byreference for all purposes.

BACKGROUND

With a proliferation of different types of networked devices, a singleuser that in the past may have only had one computer or one phone maynow have a desktop computer, a laptop computer, a mobile phone, atablet, networked wearable devices, networked home appliances, and othernetworked devices. Managing communications in such an environment is anincreasingly complex task.

As part of such communications, various types of acknowledgements arecommonly used in communications systems. Acknowledgements provideverifications to a sending device that a previously sent communicationwas received. In various protocols such as the standard transmissioncontrol protocol (TCP), which is a core protocol of the internetprotocol (IP) suite, acknowledgements are used as part of many or allcommunications. Standard acknowledgements provide information indicatingthat a communication was received, which can verify that there is noissue with a transmission channel. But, such acknowledgements may notprove helpful in some situations.

Embodiments described herein may include devices, systems, and methodsfor managing communications in this context.

BRIEF SUMMARY

Embodiments can provide methods, systems, and devices forapplication-level acknowledgements. For example, application-levelacknowledgements may be used to verify that a data packet has not onlybeen received, but has been successfully processed by the appropriateapplication operating on a device that received the data packet. Forexample, in one embodiment, two devices may be registered with anidentity service that enables security and push messaging. A firstdevice may communicate a data packet to another device that isassociated with the same identity account through the identity service.The device receiving the data packet may send an acknowledgementverifying receipt of the data packet. After an application has processedthe data packet, an acknowledgement that the data packet was processedmay also be send from the second device to the first device.

Other embodiments are directed to systems, portable consumer devices,and computer readable media associated with methods described herein.

A better understanding of the nature and advantages of embodiments ofthe present invention may be gained with reference to the followingdetailed description and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system composed of one or more clients,hosts (e.g., a companion device), and servers communicating messagesamong each other according to various embodiments.

FIG. 2 is a block diagram of system that provides push notificationservices according to various embodiments.

FIG. 3 is a diagram of first and second devices that may useapplication-level acknowledgements in communication with one anotheraccording to various embodiments.

FIG. 4 illustrates a signal flow for application-level acknowledgementsaccording to various embodiments.

FIG. 5 illustrates a method by a sending device for application-levelacknowledgements according to various embodiments

FIG. 6 illustrates a method by a receiving device for application-levelacknowledgements according to various embodiments.

FIG. 7 shows a protocol stack for communicating data according toembodiments of the present invention.

FIG. 8 is a block diagram of a portable electronic device or mobiledevice according to embodiments of the present invention.

DETAILED DESCRIPTION

Embodiments herein relate to the used of application-levelacknowledgements as part device communications. In particular,embodiments may include standard transmission level (e.g. TCP)acknowledgements, messaging-level acknowledgements that indicate amessaging process of a receiving device has accepted a data packet, andapplication-level acknowledgements that indicates an application on thereceiving device has successfully processed the incoming data packet.

For example, in one embodiment, a user's phone may communicate with awearable device such as a network enabled wristwatch to synchronizephotos between the watch and the phone by sending data from the phone tothe watch. The phone and the wristwatch may each be running photoapplications that communicate with each other as part of thesynchronization. The applications may each rely on various daemons orcommunication management processes on the associated devices that assistwith communication between applications.

Rather than simply relying on applications to receive a communication,process the communication, and then initiate a separate communication toindicate that the received information has been processed, themanagement processes may implement an acknowledgement system. When thewatch receives data from the phone, a management process may communicatean acknowledgement back to the phone that the data was received. Themanagement processes on the watch may then pass the data to theapplication on the watch. When the application returns to the managementprocesses after disposing of the data, the management processes may thensend an additional acknowledgement (e.g., indicating that theapplication processed the data) back to the phone. When the phone eitherreceives or fails to receive one or more of the acknowledgements, thephone may make use of this information to make decisions on futurecommunications.

I. Introduction

In some embodiments, network servers may interact with the managementprocesses to assist with the communications. For example, a managementframework or management proxy may exist in a communication path betweenthe phone and the device. Such a management proxy may assist withretransmission of data that is not correctly processed, and may provideother information to the devices to assist with communications betweenthe devices.

A. System

FIG. 1 is a block diagram of a system 100 according to variousembodiments. FIG. 1 and other figures are merely illustrative of anembodiment or implementation, or of aspects of an embodiment orimplementation disclosed herein, and should not limit the scope of anyinvention as recited in the claims. One of ordinary skill in the art mayrecognize through this disclosure and the teachings presented hereinother variations, modifications, and/or alternatives to thoseembodiments or implementations illustrated in the figures. FIG. 1 is oneexample of a system which may use application-level acknowledgementsaccording to various embodiments. The devices in system 100 can includehardware and/or software elements.

In one embodiment, system 100 includes an identity managementinfrastructure 105 (i.e., one or more servers that implement an identitymanagement service, authorization service, and/or authenticationservice), content infrastructure 110 (i.e., one or more servers thatimplement a voice/video call service, a messaging service, and/or a pushnotification service), mobile device 115, companion device 120, userdevice 125, provider 130, provider 135, and communications network 140.As illustrated, identity management infrastructure 105, contentinfrastructure 110, mobile device 115, companion device 120, user device125, provider 130, and provider 135 are each capable of communicatingwith and through communications network 140 (representing the Internet,wide area networks (WANs), metropolitan area networks (MANs), local areanetworks (LANs), wireless area networks (WiLANs), radio access network(RANs), public switched telephone network (PTSN), etc., and/orcombinations of the same). As illustrated, mobile device 115 cancommunicate directly with companion device 120 without utilizingcommunications network 140.

Identity management infrastructure 105 may be implemented in variousembodiments using a single server computer system or may includemultiple server computer systems, web servers, application servers,networks, interconnects, and the like. In various aspects, identitymanagement infrastructure 105 provides management of individualentities, their authentication, authorization, and privileges within oracross systems, such as content infrastructure 110. Identity managementservices provided by identity management infrastructure 105 can includetechnologies and services such as Active Directory, identity providers,password managers, access control providers, single sign-on (SSO)services, OAuth, security token services, or the like.

In various embodiments, identity management infrastructure 105 maintainsinformation that authenticates the identity of a managed entity (such asa user, organization, and any associated devices, resources, services,applications, or the like). Identity management infrastructure 105 canverify that an entity is who/what it claims to be using a password,biometrics such as a fingerprint, a distinctive behavior such as agesture pattern on a touchscreen, challenge-response protocols, one-timepasswords (OTPs), 2-way authentications, and other techniques. Identitymanagement infrastructure 105 further can manage authorizationinformation that defines what operations an entity can perform in thecontext of a specific application, service, or resource. Someauthorizations may be based on a role, device type, application,application type, or the like associated with a managed entity. Usersare granted roles often related to a particular job or job function.Identity management infrastructure 105 can also manage descriptiveinformation about managed entities and how and by whom that informationcan be accessed and modified. As part of identity management, one ormore host devices may be identified and associated with one or moreclient devices, such that incoming calls, text messages, or othercommunications to the host devices may be relayed to the client devices.In certain embodiments, communications as part of these processes mayuse application-level acknowledgements.

In some embodiments, identity management infrastructure 105 createsdigital identities for managed entities encompassing, for example,entity identifying information (PII) and ancillary information. In oneaspect, a managed entity can have multiple digital identities and eachdigital identity can encompass multiple attributes. For example, a usercan have a user identifier (e.g., a phone number, e-mail, etc.) that islinked to multiple devices. In addition to creation, deletion,modification of digital identities, identity management infrastructure105 can manage ancillary entity data for use by services, such contentinfrastructure service 110.

In further embodiments, identity management infrastructure 105 can storecapabilities of each device associated with a user identifier. Examplesof device capabilities include whether a device includes a specific typeor version of hardware, whether a device includes a specific type orversion of software (e.g., operating systems or applications), whether adevice is capable of performing a specific function such as placing andreceiving phone calls or sending and receiving short message service(SMS)/multimedia message service (MMS) messages, whether a device iscapable of maintaining connections with other devices, or the like. Thelist of devices associated with a user can be sent to and stored at anyother device of that user, such as mobile device 115 and companiondevice 120 when associated with the same user identifier. Identitymanagement infrastructure 105 can determine and collect capabilities ofa device when it is registered and associated with the user identifier.Identity management infrastructure 105 can update the capabilities of adevice periodically, for example, when the device re-registers orcommunicates with one or more services managed by identity managementinfrastructure 105.

In various embodiments, identity management infrastructure 105 canreceive a single user identifier, which is used to determine deviceidentifiers for devices associated with the user identifier. Duringentity registration, in order to access services or resources managed byidentity management infrastructure 105, one or more user or otheridentifiers and a unique entity or device identifier (UID) may becombined to generate an entity or device token. In various embodiments,the token is encrypted by applying a hashing algorithm (e.g., SHA-0,SHA-1, SHA-2, MD5, Whirlpool, or other hashing algorithms). The tokengenerated and encrypted for an entity can remain constant in variousembodiments. Once a token has been generated and encrypted by identitymanagement infrastructure 105, the token can be sent back to the entity.The entity in some aspects can then distribute the token to services orresources managed by identity management infrastructure 105 or otherthird party services for a variety of purposes relating toauthentication, authorization, accounting, or the like of the entity atthose managed services or resources or the trusted delivery of contentto the entity by the third parties.

Content infrastructure 110 may be protected by and/or accessible toentities managed by identity management infrastructure 105. Contentinfrastructure 110 may be implemented in various embodiments using asingle server computer system or may include multiple server computersystems, web servers, application servers, networks, interconnects, andthe like.

Content infrastructure 110 can provide content to mobile device 115,companion device 120, and user device 125 as well as to other devicesand entities. Examples of content include a text message, a multimediamessage, an impending calendar event, an audio/video call (e.g., usingVOIP), or a notification of new data on a remote server. In oneembodiment, the content can originate from one or more sources managedby identity management infrastructure 105 or provided directly bycontent infrastructure 110. In other embodiments, the content canoriginate from other sources. For example, content may originate fromany one of mobile device 115, companion device 120, user device 125, andproviders 130 and 135.

In another example, content may be received from other sources such asthe Internet, cellular networks, public switched telephone networks, andthe like. Content infrastructure 110 can then route the content tomobile device 115, companion device 120, user device 125, and providers130 and 135. In one embodiment, content infrastructure 110 may routethrough the infrastructure an SMS message received from or destined to acellular network. In another embodiment, content infrastructure 110 mayroute through the infrastructure a voice call received from or destinedto a public switched telephone network.

In some embodiments, the content sent to mobile device 115 can beforwarded to companion device 120 for delivery to mobile device 115.Companion device 120 can also act and send signals on behalf of mobiledevice 115. In these embodiments, companion device 120 acts as a main orintermediary device and mobile device 115 acts as a proxied device.Content infrastructure 110 can coordinate how and whether companiondevice 120 can act and send signals on behalf of mobile device 115.

In some embodiments, content infrastructure 110 can send content to morethan one device, when appropriate. A user may be associated with bothmobile device 115 and companion device 120. Content infrastructure 110may route the content to both mobile device 115 and companion device120, such as to have a VOIP phone call ring on both devices or to have amessage appear in the inbox of the same application installed on bothdevices. In other embodiments, content is sent to only one device, e.g.,to companion device 120, which may forward a call to mobile device 115.When a call is being forwarded to a device, a phone number can identifywhich device is to receive the phone/video call, and that device canrelay a call between devices as appropriate.

In one aspect, content can include of one or more pieces of data, suchas a device identifier (or token) as discussed above and a payload. Adevice token can be provided in content originating from a provider(e.g., provider 130 and/or 135), a device of a same user (e.g., fromeither mobile device 115 or companion device 120), or a device ofanother user (e.g., user device 125), together with any payload theprovider seeks to have delivered using content infrastructure 110. Thedevice token can contain information that enables content infrastructure110 to locate a device on which a particular service or clientapplication is installed and that is registered to receive the content.The payload may include new information received at a server applicationor a reference to where the information is to be found. The payload mayfurther include a property list that specifies how the user is to bealerted about this new information by the particular service or clientapplication.

An alert can come in a variety of forms. In one example, content can bedisplayed to a user as an alert message or other visual representation,such as a badge associated with an application icon. Availability of thecontent further can be announced by playing a sound when an alert orbadge is shown. When a user is notified that an application or servicehas a message, event, or other content data for them, they can launchthe application or service and see the details by either viewing thecontent, viewing information contained in a push notification, havingthe client application retrieve the referenced information, or the like.The user can also choose to ignore the notification, in which case theapplication is not activated.

As alluded to above, content infrastructure 110 can include pushnotification services that in addition to or in the alternative ofrouting content implement mechanisms to give client applications of pushproviders that are on user devices the ability to let users know thatnew content is available at one or more server applications, is on thedevice, or is incoming. A push provider (or simply provider) as usedherein can refer to an entity having information to be forward and/ordelivered using a push notification infrastructure. Generally, softwaredevelopers (acting as providers) originate notifications in their serversoftware when new data is available for users. A provider connects itsserver software with content infrastructure 110 through a persistent andsecure channel. Identity management infrastructure 105 can ensure thatthe provider is authenticated (e.g., that the provider is who theprovider alleges to be) and authorized to connect and utilizes contentinfrastructure 110 in a trusted manner.

While monitoring for incoming data intended for its client applications,when new data for an application arrives, the provider prepares andsends in one aspect a notification through its channel connection tocontent infrastructure 110, which pushes the notification to a pushconsumer or destination target device. Identity managementinfrastructure 105 can also ensure that the consumer or destinationtarget device is authenticated and authorized to connect to and utilizesservices of content infrastructure 110 in a trusted manner. A pushconsumer (or simply consumer or destination) can refer to an entitydesignated to receive information forwarded and/or delivered usingcontent infrastructure 110. Although the above describes a provider asthe originator of content or a notification of available content for thesake of simplicity, a provider in one instance may in turn become aconsumer in another, and vice versa. Additionally, mobile device 115 maybe a provider of content to companion device 120, and vice versa as wellhas provider 130 providing content to provider 135, and vice versa.

In one example of operation of content infrastructure 110, one or moreserver computers provide, provision, manage, and otherwise operate thepush notification service for propagating information between provider130, provider 135, mobile device 115, companion device 120, and userdevice 125. Each may establish at least one persistent connection (e.g.,an accredited and encrypted Internet protocol (IP) connection) withcontent infrastructure 110 to originate and/or receive content over thispersistent connection. As noted above, each and their connections can beauthenticated and authorized by identity management infrastructure 105.

If a notification delivered by content infrastructure 110 for anapplication associated with a user's device arrives when the applicationis not running, the user's device may alert the user that theapplication has data waiting for it as discussed above. Contentinfrastructure 110 may also provide a default quality-of-servicecomponent that provides store-and-forward capabilities. If contentinfrastructure 110 attempts to deliver a notification but a targetdevice is offline, the notification can be stored for a limited periodof time, and delivered to the device when it becomes available. In someembodiments, all recent notification for a particular application isstored. In some embodiments, only one recent notification for aparticular application is stored. For example, if multiple notificationsare sent while the device is offline, each new notification causes theprior notification to be discarded. This behavior of keeping only thenewest notification is referred to as coalescing notifications. In otherembodiments, if the device remains offline for a long time, anynotifications that were being stored for it may be discarded.

Provider 130 and provider 135 may be implemented in various embodimentsusing a single server computer system or may include multiple servercomputer systems, web servers, application servers, networks,interconnects, and the like. In various aspects, provider 130 andprovider 135 provide client applications that run on mobile device 115,companion device 120, and user device 125 and server applications thatprovide one or more services to which the client applications canconnect. Provider 130 and provider 135 may seek to notify the clientapplications accessible to one or more of mobile device 115, companiondevice 120, and user device 125 that information is available to theirrespective users.

In one aspect, a push provider is a software developer, company, ororganization that maintains server software configured to interact withone or more client applications on one or more of mobile device 115,companion device 120, and user device 125. Provider 130 and provider 135each connect with content infrastructure 110 through a persistent andsecure channel while monitoring incoming data intended for their clientapplications. In one embodiment, provider 130 and provider 135 connectover a binary interface that provides a high-speed, high-capacityinterface, e.g., using a streaming TCP socket design in conjunction withbinary content. The binary interface may be synchronous or asynchronous.For each interface, TLS (or SSL) may be used to establish a securedcommunications channel.

Mobile device 115, companion device 120, and user device 125 may be eachembodiment as a single device, a single computer system, multipledevices, or multiple computer systems. In various aspects, mobile device115, companion device 120, and user device 125 although labeleddifferently for convenience can each be embodied as a mobile device, awearable device, or other mobile device (e.g., a laptop, palmtop, mobilephone, smart phone, multimedia phone, portable media player, GPS unit,mobile gaming systems, etc.). As examples, a wearable device can be awrist worn device, a device that is clipped or pinned to the user'sclothing, a device with a lanyard or chain that is wearable around theuser's neck, a headband device, eyeglasses, or any other device that canbe secured to the user's person or clothing.

In addition to or in the alternative, companion device 120 and userdevice 125 can be embodied as described above as well as being embodiedas personal computer systems, mainframes, server computer systems, cloudservices, or the like. Mobile device 115, companion device 120, and userdevice 125 may include a variety of technologies that provide acommunications connection. Some examples of connection technologiesinclude wired connections (e.g., Ethernet, fiber, digital subscriberline (DSL), etc.) and wireless connections (e.g., Wi-Fi, Bluetooth,WiMax, 3G, 4G, LTE, etc.).

In one aspect, mobile device 115, companion device 120, and user device125 host one or more of a variety of client applications thatcommunicate with one or more server applications provided by one or moreproviders (e.g., providers 130 and 135). These client applications mayinclude applications specific to the intended function of a device (suchas telephony applications or GPS applications) as well as e-mailclients, update/upgrade clients, news clients, web/blog clients, podcastclients, social networking clients, or other types of clientapplications where notification messages may be sent. These clientapplications may represent to a user one or more notification messagesreceived using content infrastructure 110. Notifications can berepresented to users in one or more manners defined by an operatingsystem of the device, a graphical user interface toolkit, and/or theapplications themselves. Some examples of representations ofnotifications include a new e-mail indicator, a new news item indicator,a new podcast indicator, a change of on-line status of a socialnetworking friend, and the like. In various embodiments, another serviceoperating on a device can handle notifications for client applications.

As discussed above, mobile device 115, companion device 120, and userdevice 125 may receive an identifier (or device token) when a clientapplication initially connects with content infrastructure 110 in orderto receive push notifications. Providers 130 and 135 can use the token,or include the token, with any content or notification message so thatit can be appropriately forwarded back to the device using contentinfrastructure 110. In various embodiments, to ensure trust, a providercommunicates the token every time it connects with contentinfrastructure 110. Content infrastructure 110 can decrypt the devicetoken and validate using identity management infrastructure 105 that thetoken was generated for the destination device. To validate in oneembodiment, content infrastructure 110 ensures that the deviceidentifier contained in the token matches the device identifier in adevice certificate used when the device registered with identitymanagement infrastructure 105.

Referring to an operation of system 100 illustrated in FIG. 1, in oneembodiment, the operation can be to forward or otherwise communicate anotification message from provider 130 to companion device 120 asillustrated by path 145. In various embodiments, provider 130 sends anauthentication Secure Sockets Layer (SSL) certificate upon an initialconnection with content infrastructure 110. Identity managementinfrastructure 105 can authenticate and authorize provider 130 as aregistered and authorized sender of push notifications. This SSLcertificate can also be configured with additional user-defined data.Identity management infrastructure 105 can utilizes the additionaluser-defined data to identify provider 130 in a trusted fashion. Othersecure communications protocols (e.g., cryptographic protocols such asTransport Layer Security (TLS), etc.) can be used in other embodiments.

In some embodiments, where provider 130 is associated with a particularapplication (e.g., Email, Facebook, or Twitter) and includes additionalidentifying (e.g., user-defined) data within the SSL certificate,identity management infrastructure 105 can not only authenticateprovider 130, but also automatically provision push service for provider130 and the application utilizing content infrastructure 110. In otherwords, identity management infrastructure 105 can automatically extractany additional identifying data from the authentication certificate andhave content infrastructure 110 attach the additional identifying data(or a portion of the data) to content (e.g., push-notificationmessages). In some embodiments, the additional identifying data mayidentify a topic or feed associated with provider 130 (or an applicationof provider 130) to which a user might subscribe via contentinfrastructure 110. Thus, the additional information in theauthentication certificate can be leveraged to direct content to devicesthat have subscribed to the topic/feed or requested informationregarding the topic/feed. In this way, push service is automaticallyprovisioned for provider 130.

Once provider 130 is trusted, content infrastructure 110 receives thenotification message from provider 130. As discussed above, thenotification message may include a device token. Having received thenotification message from provider 130, content infrastructure 110determines the destination for the notification message. In variousembodiments, the destination is determined based on the device tokenthat is sent along with notification message. In some embodiments, it isnot necessary to send destination information as part of a token. Bydetermining or extracting the destination from the device token orotherwise obtaining destination information for the content, contentinfrastructure 110 can then determine whether the destination is“online” or otherwise accessible.

If the destination is online, in one embodiment, content infrastructure110 may then route the notification message to the destination companiondevice 120 illustrated by path 150, for example, via a persistentconnection maintained by companion device 120 with contentinfrastructure 110. If the destination is “offline” or otherwiseinaccessible to content infrastructure 110, the content may be storedand delivery retried at a later time. Content infrastructure 110 can inaddition to or alternatively route the notification message to mobiledevice 115 illustrated by path 155, for example, via a persistentconnection maintained by companion device 120 with contentinfrastructure 110. Content infrastructure 110 thus can route content toa single device, multiple devices at the same time, or to one device fordelivery to another device.

B. Content Infrastructure

FIG. 2 is a block diagram of system 200 that may use application-levelacknowledgements with certain communications. In particular, IDSservices as described herein, including IDS 205, may be used tofacilitate discovery and communication between a devices that a party toa communication which may use application-level acknowledgements. Incertain embodiments, different applications on a single device may beprovided identifiers by IDS services. This may assist with variousembodiments of communications between applications and associatedapplication-level acknowledgements as described herein. System 200 canbe embodied as content infrastructure of FIG. 1 in various embodiments.

In particular, FIG. 2 illustrates various examples of forwarding content(e.g., notification messages and phone/video calls) between devices,e.g., between providers and mobile devices, or between a sending deviceof one user and receiving devices of another user). In these examples,system 200 is shown with identity services (IDS) 205 having interface210 and identity management server (IMS) 220 and push notificationservices (PNS) 220 having provider interface 225, gateway 230 havingpresence information 235, device interface 240 having connectioninformation 245, and user device 250. Each service may be implementedusing hardware and/or software elements.

In one aspect, IDS 205 may be embodied as or form part of identitymanagement infrastructure 105. IDS 205 may be implemented in variousembodiments using a single server computer system or may includemultiple server computer systems, web servers, application servers,networks, interconnects, and the like. Interface 210 can enable anentity (e.g., mobile device 115 or provider 130) to connect (e.g., via anetwork) in order to take advantage of service provided by IDS 205.Interface 210 may incorporate load balancing and other connectionmanagement techniques allowing entities to communicate with Identitymanagement server 215.

In one embodiment, an entity sends information such as an authenticationcertificate that is received via interface 210 upon an initialconnection to IDS 205 or to a service, resource, or application managedby IDS 205 (e.g., PNS 220). Identity management server 215 canauthenticate and authorize a device, user, or organization sending theinformation as a registered and authorized entity. One or more types ofservices can be authorized or provisioned for the device, user, ororganization (e.g., call services, instant messaging services, chatservices, notification services, etc.). To support a security model forPNS 220, entities and their devices may be required to possess certaincertificates, certificate authority (CA) certificates, or tokens.

In one embodiment, each provider of content uses a unique providercertificate and private cryptographic key for validating theirconnection with PNS 220. This certificate can be provisioned by identitymanagement server 215 and identify the provider and/or a particulartopic published by the provider. In general, the topic is a bundle ID ofa client application. The provider may optionally wish to validate theservice, to which the provider is connected, using a public servercertificate provided by PNS 220. In various aspects, the provider usesthe public server certificate passed to it by identity management server215 when registering to authenticate the service to which the providerhas connected.

Identity management server 215 may also issue to each device, whichdesires to receive content, a unique private key and certificate thatthe device uses to authenticate itself to identity management server 215and establish a connection to PNS 220. A device usually obtains a devicecertificate and key from identity management server 215 during deviceactivation and stores them in a keychain. The device also holds itsparticular device token, which it receives during the service connectionprocess. Each client application that utilizes PNS 220 is responsiblefor delivering this token to its content provider.

Identity management server 215 may store any necessary certificates, CAcertificates, and cryptographic keys (private and public) for validatingconnections and the identities of providers and devices.

In this example, once the entity is trusted, system 200 allows theentity to utilize push notification services provided by PNS 220. PNS220 may be implemented in various embodiments using a single servercomputer system or may include multiple server computer systems, webservers, application servers, networks, interconnects, and the like. Theentity may be a provider or other notification provider desiring toconnect with PNS 220 (e.g., via a network). As alluded to above, in oneembodiment, provider interface 225 provides a high-speed, high-capacityinterface allowing push notification providers to communicate with PNS220. Provider interface 225 may incorporate load balancing and otherconnection management techniques allowing entities to communicate withPNS 220. Although provider interface 225 is shown as being linked togateway 230, provider interface 225 may be incorporated into gateway 230or device interface 240. As discussed above, a user device can be aprovider of content in various embodiments as well as be a destinationof content routed using PNS 220.

Gateway 230 may be implemented in various embodiments using a singleserver computer system or may include multiple server computer systems,web servers, application servers, networks, interconnects, and the like.Gateway 230 can determine the destination of content (e.g., pushmessages or call messages) received via provider interface 225 or deviceinterface 240. In various embodiments, gateway 230 can determine adestination based on presence information 235. In one aspect, presenceinformation 235 is maintained using a device's push token. Accordingly,when a push notification is received at gateway 230 directed to aparticular push token, gateway 230 can perform a lookup to determinewhether there is a TCP socket descriptor associated with that pushtoken. The socket descriptor can provide the TCP socket information andother networking information needed to transmit the push notification.In various aspects, presence information 235 includes mappings betweenauthenticated entities and their connections to PNS 220. Theseconnections can be utilized by PNS 220 for delivering content,notifications, and the like or otherwise communicating with an entity.Each mapping may be indicative of at least one entity and at least oneconnection mechanism to that entity, such as a network socket connectionor other connection identifier. For example, a mapping may identify adestination device by its device token or a provider by its provideridentifier. Additional information may be included in each mapping inorder to facilitate communication with the entity's device.

In some embodiments, in order to scale handling of connections from anincreasing number of users, devices, and providers utilizing services ofPNS 220, device connections in presence information 235 (or the devicesthemselves) may be managed according to at least one grouping or logicalpartition called a zone. Functions performed by gateway 230 may bepartitioned out to multiple servers that are assigned dynamically tohandle these groupings or zones. For example, one or more servers mightmanage, for a period of time, delivery to destinations assigned to onezone and then be switched, or reconfigured, to manage the delivery ofnotifications to destinations assigned to a different zone at a latertime. Each of these servers may also include routing information that isused to route content to other servers associated with a particular zoneof the destination of the content. Thus, when content is received at oneserver, another server designed to handle a predetermined zone isdetermined and the content can be forwarded to the appropriate server.In one aspect, functions performed by gateway 230 may be partitioned outto multiple servers to handle corresponding device connections (e.g.,device interface 240).

In various embodiments, gateway 230 is linked to device interface 240.Device interface 240 provides an interface to communicate with userdevice 250. Device interface 240 may incorporate load balancing andother connection management techniques allowing devices to communicatewith PNS 220. Although device interface 240 is shown as being linked togateway 230, device interface 240 may be incorporated into gateway 230or provider interface 225.

Device interface 240 in these examples allows presence information 235to be generated when device interface 240 is connected to user device240. User device 240 can assert its presence to PNS 220 uponestablishing a persistent connection. Device interface 240 thengenerates a device/connection mapping in connection information 245.Device interface 240 can back-propagate connection information 245 togateway 230 allowing gateway 230 to generate a device/connection mappingin presence information 235. In one aspect, presence information 235includes a device/courier mapping or link allowing gateway 230 todetermine an appropriate courier that acts as device interface 240connected to user device 250. The courier utilizes connectioninformation 245 (including any device/connection mappings or links)allowing the courier to determine connection information specific touser device 250 that can be used to deliver content to user device 250.In another aspect, presence information 235 and connection information245 may be substantially identical in that they include correspondencesbetween a given device and its connection with PNS 220.

In various embodiments, a device wishing to receive content via PNS 220sends authentication information either upon an initial connection withdevice interface 240 or directly to IDS 205. Identity management server215 can receive the authentication information either directly orindirectly and then authenticate and authorize the device or itsassociated user or organization as a registered and authorized entity.Once the device is trusted, PNS 220 is informed and PNS 220 thereaftermanages any connections made between the device and PNS 220 (such aswith device interface 240 in connection information 245). Deviceinformation available at device interface 240 in connection information245 can be periodically back-propagated to gateway 220 to generate orupdate presence information 235.

When the device initially connects with PNS 220, PNS 220 provisions thedevice. In various embodiments, a zone is provisioned for the device asalluded to above. Despite a particular zone assignment for each device,devices may lose their connection with device interface 240 for variousreasons. For example, a connection might be lost due to loss of cellularsignal, or Wi-Fi signal, loss of power, or because a mobile device haschanged geographic locations, etc. In other aspects, a connection may beintermitted as opposed to being persistent in order to conserve power orachieve other efficiency metrics.

When user device 250 attempts to reconnect to PNS 220, user device 250can connect with any courier acting as device interface 240. Inembodiments where device connections are assigned to at least onegrouping or zone, device interface 240 may provision a connection withone or more servers of gateway 230 that are assigned to handle the zoneof a connecting device. For example, if device interface 240 isconnected to user device 250 that is assigned to zone 1, then deviceinterface 240 can provision a connection with one or more serversresponsible for managing zone 1. Device interface 240 may thenback-propagate device information for user device 250 to the one or moreservers responsible for managing zone 1. In similar fashion, deviceinterface 240 may make connections with servers of different zones toback-propagate specific device information for devices associated withthose respective zones ensuring that no matter where or how user device250 connects to PNS 220, presence information 235 is up to date andavailable to determining how to route the content. In some embodiments,device interface 240 can be specific to a wireless carrier or internetservice provider (ISP) allowing PNS 220 to support the protocols orphysical connections specific to multiple third party entities.

According to one example, when gateway 230 receives content fromprovider interface 225, gateway 230 forwards the content received fromprovider interface 225 to device interface 240 based on its mappings inpresence information 235. Device interface 240 can deliver the contentreceived from gateway 230 to user device 250 for which information abouta persistent connection is maintained in connection information 245.

Upon receiving content from gateway 230, device interface 240 canperform a lookup or otherwise consult its device connections inconnection information 245 and send the content received from gateway230 to the appropriate device, for example, over the persistentconnection associated with user device 250. In one aspect, deviceinterface 240 inspects the device token associated with the content tobe delivered and determines whether a match is found between the devicetoken and the connections that device interface 240 manages inconnection information 245. Device interface 240 can deliver the contentusing the connection established by the device having the given devicetoken.

In one example of operation, user device 250 subscribes to a particularapplication managed by a provider and desires to receive notificationmessages for that application via PNS 220. Thus, user device 250 callsthe provider either directly via a communications network or utilizingPNS 220 and transmits its device token to the provider. The device tokenor its transmission may include not only a device's identificationinformation but may include an encrypted combination of a device's UIDand its zone identifier allowing PNS 220 to provision connectioninformation for the device according to the appropriate resourcesallocated to the zone.

When the provider sends a notification message to the particularapplication on user device 250, the provider connects to PNS 220 usingprovider interface 225 and sends the message to gateway 230. Even ifuser device 250 is associated with a particular zone, the provider doesnot need to connect to any particular gateway of PNS 220 to successfullypush a notification message to user device 250. For example, if gateway230 receives content from provider interface 225 and the content has adevice token, gateway 230 will look at the token and either route themessage to an appropriate server of PNS 220 (which may route the messageto device interface 240 or another courier of PNS 230) or route themessage directly to device interface 240.

If gateway 230 is the designated gateway, gateway 230 sends/forwards themessage to device interface 240 based on its device/courier mapping inpresence information 235 in some embodiments. Device interface 240 isthen able to lookup its connections in connection information 245 andsend the message to the device over the persistent connectionestablished by the device with device interface 240. In summary, incases where PNS 220 receives a message having a particular destination,a gateway of PNS 220 forwards that message directly to an appropriatecourier of PNS 220 using a device/courier mapping that was establishedwhen a device connects to PNS 220. In further embodiments, gateway 230can send/forward the message directly to user device 250 based on itsdevice/connection mapping in presence information 235. Gateway 230 cangenerated this mapping information from various sources to each of whicha device has established a connection.

II. Application-Level Acknowledgements

A. System and Device Embodiment

FIG. 3 is a diagram of first and second devices that may useapplication-level acknowledgements in communication with one anotheraccording to various embodiments. FIG. 3 includes first device 300,second device 350, IDS 205, and PNS 220. These devices may be connectedby network connections 388 and connection 338.

Devices 300 and 350 may be any device accessible by a network interface,including a desktop computer, a laptop computer, a smartphone, a tabletcomputer, a wearable device (e.g. a network enabled watch, earpiece, ornecklace,) a networked appliance (e.g. a network enabled refrigerator orclothes washer,) media player, personal digital assistant, key fob,access card, multi-function device, game system, or any other suchclient device. An device, client device, mobile device, host device, orany other such device described herein will include processingresources, memory resources, and networking resources. One embodiment ofa device illustrating such resources is shown and described with respectto FIG. 7, though it will be apparent that other structures for a devicemay be possible according to different embodiments.

Different embodiments may implement connection 338, network connections388, or aspects of these connections using one or more communicationprotocols or technologies, including time division multiple access(TDMA), code division multiple access (CDMA), global system for mobilecommunications (GSM), Enhanced Data GSM Environment (EDGE), widebandcode division multiple access (W-CDMA), Long Term Evolution (LTE),LTE-Advanced, Wi-Fi (such as IEEE 802.11a, IEEE 802.11b, IEEE 802.11gand/or IEEE 802.11n), Bluetooth, Wi-MAX, voice over Internet Protocol(VoIP), near field communication protocol (NFC), a protocol for email,instant messaging, and/or a short message service (SMS), synchronousoptical network (SONET), Ethernet (IEEE 802.3), or any other suitablecommunication protocol, including communication protocols not yetdeveloped as of the filing date of this document. A host or clientdevice can include wireless circuitry as part of wireless interfaces,such as network interface 312, network interface 362, and wirelessinterface 364, that can communicate over several different types ofwireless networks depending on the range required for the communication.For example, a short-range wireless transceiver (e.g., Bluetooth), amedium-range wireless transceiver (e.g., Wi-Fi), and/or a long rangewireless transceiver (e.g., GSM/GPRS, UMTS, CDMA2000 1x/EV-DO andLTE/LTE-Advanced) can be used depending on the type of communication orthe range of the communication.

Connection 338 in particular may, in certain embodiments be implementedas a peer to peer (P2P) wireless connection directly between networkinterface 312 and network interface 362. In other embodiments,connection 338 may include multiple additional devices andsub-connections, including multiple access points, network routingconnections, and communication servers.

In additional alternative embodiments, connection 388 may function asthe sole connection between first device 300 and second device 350, withIDS 205 and/or PNS 220 functioning as a communication path for firstdevice and second device 350 to communicate with each other. In suchembodiments, IDS 205 or PNS 220 may operate as a proxy, and may thenstore portions of communications between the devices and retransmit orrelay communications and acknowledgements if needed.

Wireless circuitry may be used in conjunction with wireless interfacessuch as wireless implementations of network interfaces 312 or 362 tosend and receive information over wireless connections such asconnections 338 and 388. Any device described herein may additionallyinclude conventional circuitry such as an antenna system, an RFtransceiver, one or more amplifiers, a tuner, one or more oscillators, adigital signal processor, a CODEC chipset, memory, etc. to enablevarious wireless connections as described herein.

Circuitry of network interfaces 312 and 362 may be coupled to processingresources of their respective devices. Data packets received bycircuitry of an interface may be sent to one or more processors viaperipheral interfaces. The processing resources of first device 300 maybe used to implement client device processes such as application 302,IDS daemon 304, and push daemon 306. Similarly, processing resources ofsecond device 350 may be used to implement device processes such asapplication 352, IDS daemon 304, and push daemon 306.

A daemon as described herein is a process that may be implemented inhardware, firmware, or software on a computing device. A daemon runs asa background process rather than being under the direct control of auser.

IDS daemon 304 may function as a service operating on first device 300to work with IDS 205 to provide device identities for use incommunication processes. Any service described above for IDS 205 mayfunction, in part, using IDS daemon 304 to implement local aspects ofidentity services for device 300. In certain embodiments, for example,IDS daemon 304 may communicate with IDS 205 via network interface 312 toreceive a second device identity with is associated with second device350. This may enable addressing for communications from first device 300to second device 350 that use application-level acknowledgements. IDSdaemon 354 may provide similar functionality for second device 350.

Also similarly, push daemon 306 may function as a service operating onfirst device 300 to work with PNS 220 to provide push services for usein communication processes. Any service described above for PNS 220 toprovide push functionality may, in part, function using push daemon 306to implement local aspects of push services for device 300. In certainembodiments, push daemon 306 may receive communications from PNS 220identifying connections with second device 350 that may be used fortransmission of data packets with multiple different types ofacknowledgements.

IDS daemon 304, push daemon 306, IDS 205, PNS 220, IDS daemon 354, andpush daemon 356 may, in certain embodiments, all be considered aspectsof a communication management system including communication managementprocesses that assist in communications between application 302 of firstdevice 300 and application 352 of second device 350. For example, incertain embodiments, IDS daemon 304 may work with IDS 205 to identifysecond device 350 as a correct and secure target for a communicationfrom first device 300. IDS daemon 304 and push daemon 306 may then worktogether to communicate one or more data packets as part of thecommunication from network interface 312 to network interface 362. Thismay be done with TCP packets where the communication between networkinterface 312 and network interface 362 includes TCP acknowledgements.

When a data packet is accepted by push daemon 356 or IDS daemon 354,these management processes may communicate an acknowledgementidentifying receipt of the communication either to the managementprocesses of first device 300, to IDS 205, to PNS 220, or to anycombination of these. The data packet may then be passed by themanagement process of second device 350 to application 352. The datapacket may include an application identifier that identifies application352 as the appropriate application to process the data packet. Forexample, a header of the data packet can specify a port that correspondsto application 352.

When application 352 finished processing the data packet, the managementprocesses of second device 350 may identify or receive notice of this,and then communicate an additional acknowledgement which indicates thatthe data packet has been processed by application 352. While thisprocess is described here as associated with a data packet, any message,file, or other unit of data may have a similar application-levelacknowledgement applied by the management processes described herein.

B. Sequence Diagram

FIG. 4 illustrates a signal flow for application-level acknowledgementsaccording to various embodiments. The sequence shows a communicationfrom first device 300 to second device 350 across connection 339. Invarious embodiments, connection 339 may comprise connection 338,connections 388, IDS 205, PNS 220, or any other such elements of apossible connection between devices. First device 300 executesapplication 302 and communication management 305, which may comprise IDSdaemon 304 and push daemon 306, or may comprise additional modules ormerged versions of such modules. Second device 350 similarly includescommunication management 355 and application 352.

In blocks 402, 404, 406, and 408, first device 300 and second device 350may each register with an identity management system and a pushnotification system such as those described above with respect to FIG. 1and FIG. 2. This may provide the devices with unique identifiers andassociate the devices with an identity or account. As part of such aregistration and association, the devices may store unique identifiersfor devices sharing an identity locally, that enables the host device tolocate client devices without the need to access an IDS server prior toinitiating a communication. In various embodiments, registration may berenewed or updated periodically or based on various triggers such assystem updates or alerts pushed from the systems.

In block 410, application 302 may initiate a message directed toapplication 352. Such a message may comprise a data packet, a datastream, a file, multiple files, or any other such message. In block 412,communication management 305 manages the message by, for example,identifying an address and a secure identity associated with the seconddevice 350. In certain embodiments, this may involve determining thatfirst device 300 and second device 350 are each associated with a singleaccount as identified by an identity management server, and that thedevices are authorized to share the information in a payload of themessage.

In block 414, the message is communicated via connection 339 to seconddevice 350. In certain embodiments, this may be a peer to peer (P2P)wireless transmission directly between the wireless interfaces of firstdevice 300 and second device 350. In other embodiments, this may be acomplex network connection involving multiple routers and access points.In still further embodiments, this may involve a connection with an IDSserver computer such as IDS 205 or a PNS network server such as PNS 220acting as a proxy. Further, this communication of block 414 may itselfinvolve acknowledgements, such as standard TCP acknowledgements.

In block 418, communication management 355 of second device 350 receivesthe message and manages a response to receiving the message. This mayinclude initiating a receipt response and initiating a passing of themessage to the appropriate application. In block 420, a receiptacknowledgement is created and sent which is a communication managementlevel operation acknowledging that communication management 355 hasingested the message. In block 422, this receipt acknowledgement iscommunicated back and in block 426, the receipt acknowledgement isreceived and processed by communication management 305 of first device300. This may then result in additional communications, or thisinformation may be stored while the system waits for additionalacknowledgements.

In block 430, application 352 receives the message from communicationmanagement. 355. The message is processed in block 432. This processingmay involve storing the message for later use, performing calculationsbased on the message, initiating another process that is ongoing basedon the message, or any other such complete or partial disposition of themessage.

In block 434, application 352 may perform an action that acknowledgessuccessful processing of the message. This response may be considered anapplication-level acknowledgement made by application 352. This mayinvolve a process of application 352 returning a focus, processingthread, or polling action to communication management 355. For example,a process that checks communication management for messages forapplication 352 may perform such a check after successful processing ofthe previously received message. Application 352 may communicate anaffirmative message to communication management 355 regarding the statusof the message. Any such status of application 352 may be observed andused as an acknowledgement that the message was successfully processed.

In block 436, communication management 355 may either accept aprocessing acknowledgement message or may observe an indication and usethe indication to create a processing acknowledgement message. In block440, the processing acknowledgement is communicated across connection339 and is then used in block 442 to update communication management305. In block 444, the receipt of one or more acknowledgements may thenbe managed, and used to determine if additional messaging will follow inblock 446.

As described above for block 414, in various embodiments, thecommunication of acknowledgements in blocks 442 and 440 may use anypossible connection such as be a peer to peer (P2P) wirelesstransmission directly between the wireless interfaces of first device300 and second device 350, a complex network connection involvingmultiple routers and access points, or a connection with an IDS servercomputer such as IDS 205 or a PNS network server such as PNS 220 actingas a proxy. These acknowledgement communications may each involveadditional acknowledgements, such as standard TCP acknowledgements.Further, the particular path followed by the message in block 414 may bedifferent than the path followed by the receipt acknowledgement in block422 or the processing acknowledgement in block 440.

As shown, the receipt acknowledgement of block 420 is communicatedseparately from the processing acknowledgement of block 436. Inalternative embodiments, block 420 may involve a delay to determine ifthe message will be processed within a predetermined period. Forexample, a one second delay may be implemented. This use of such a delaymay be performed based on a user setting, based on a power or batterylevel of the second device 350, based on the type of message at issue ora value within the message, or based on any other such criteria. If theprocessing acknowledgement is then created within the delay period, thereceipt acknowledgement and the processing acknowledgement may be sentas part of the same communication. A field value or flag may be set insuch a combined acknowledgement to allow communication management 305 toidentify that the two acknowledgements were merged, the process maycontinue with decision making as if two separate acknowledgements hadbeen received.

C. Sending Side Embodiment

FIG. 5 illustrates a method 500 by a sending device forapplication-level acknowledgements according to various embodiments. Thefirst device performing such a method may be any device comprisingwireless circuitry, a memory, and a processor such as first device 300,second device 350, or mobile device 900 described below.

At block 502, the first device communicates, via wireless circuitry,with an identity services server to receive a second identifierassociated with a second device. As described above, such acommunication may be based on information received from the application,information of an identity services daemon operating on the firstdevice, or in any other such fashion. This communication mayadditionally identify the second device as a target for a communicationincluding a payload from the application. This communication may beperformed using the same network interface or communication protocol asother, later communications in this method, or may be performed using adifferent network interface or communication protocol.

At block 504, the first device communicates a data packet to the seconddevice via the wireless circuitry. The data packet comprises the secondidentifier and a payload. The payload may include data, metadata,addressing information, or any other such information associated with acommunication. This may further involves files or data for asynchronization process, a file transfer process, a remote controlprocess, a video streaming process, a remote display process, or anyother such process. This communication may be performed by acommunication management process working alone or in conjunction with anidentity services server and/or a push notification server. Such acommunication management process may be an identity services daemon, apush notification services daemon, a combination of the two, or anyother such device process for assisting with communications thatoperates on the first device.

At block 506, the first device receives, from a communication managementprocess of the second device, a first acknowledgement indicating thatthe data packet was received at the second device. Such a communicationmanagement process of the second device may also be an identity servicesdaemon, a push notification services daemon, a combination of the two,or any other such device process for assisting with communications.

At block 508, the first device receives, from the communicationmanagement process of the second device, a second acknowledgementindicating that the payload has been processed by a second applicationoperating on the second device. As part of this receiving, and as partof any communication process listed above, additional acknowledgementsmay be sent and received as part of controls associated with differentcommunication layers than those associated with the firstacknowledgement and the second acknowledgement. An example of such anadditional acknowledgement may be TCP acknowledgements.

As communication as illustrated by FIG. 5 may include at least threedifferent types of acknowledgements within a single communicationprocess, with at least one of the acknowledgements associated withcompletion of an application process that is separate from thecommunication process. Such an application process separate from thecommunication process may involve an application storing a data packet,an application performing a calculation using a data packet, anapplication presenting information from a data packet to a user via adisplay, or any other such application initiated process that isseparate from the process of communicating the data packet betweendevices or providing the data packet to an application for initialprocessing.

D. Receiving Side Embodiment

FIG. 6 illustrates a method 600 by a receiving device forapplication-level acknowledgements according to various embodiments.Method 600 can implement application-level acknowledgements similar towhat is described for method 500, but presented from a receiving deviceinstead of a transmitting device. For ease of illustration, thereceiving device is labeled as a second device, where the first deviceis the sending device, as for method 500.

At block 602, the second device optionally communicates (e.g., using anidentity services daemon of the second device) with an identitymanagement server to receive an identifier for a first device and anidentifier for a second device. Such identifiers may be used for anyaspect of communication or security to determine whether devices areauthorized to communicate with each other.

At block 604, the second device optionally communicates e.g., using apush daemon) with a push notification server to identify an availableconnection between the first device and the second device. Inembodiments where such actions are performed, they may be performed farin advance of any subsequent communication, with information derivedfrom these communications stored for later use. In certain embodiments,these communications with service servers may be triggered by acommunication failure during a previous attempt for devices tocommunicate. This may be true for both sending and receiving devices inany communication as described herein.

At block 606, the second device receives, via the wireless circuitryfrom a first device, a data packet comprising a payload. As describedabove, in certain embodiments, such communications may be performed by aconnection with an IDS server or a PNS server acting as a proxy. Incertain embodiments, this receipt may be of a retransmission from suchan IDS server or a PNS server, where an earlier transmission was eitherlost on a poor quality connection, or lost by the receiving device priorto an application acknowledgement being sent. Thus, in certainembodiments, a sending device may send a data packet.

An IDS or PNS server may relay the data packet, and the IDS or PNSserver may then retransmit the data packet independent of anycommunication with the sending device. Such a retransmission may, incertain embodiments, be triggered by the IDS or PNS server failing toreceive a push acknowledgement, a receipt acknowledgement, an processedacknowledgement, or another acknowledgement from an applicationdisposing of the originally transmitted data packet.

At block 608, the second device delays communication of a firstacknowledgement to the first device by a threshold amount of time. Thismay enable conservation of power by consolidating two acknowledgementsinto one if the application finishes processing the data packet quickly.This may also enable errors or other actively identified problems to beconsolidated with a first acknowledgement if such errors are identifiedand returned to a communication management process quickly. In certainembodiments, the delay time or the use of any delay may be variablebased on power levels of a battery, based on user settings, or based onany other such options.

At block 610, the second device communicates a first acknowledgement tothe first device. The first acknowledgement verifies receipt of the datapacket. For example, a push daemon (e.g., 356 of FIG. 3), IDS daemon(e.g., 354), or any communication management processes can send thefirst acknowledgement to the first device. The communication of thefirst acknowledgement can occur as described herein, e.g., directly tothe first device or via a server.

At block 612, an application of the second device processes the payload.For example, application 352 in FIG. 3 can process the payload. Theapplication for processing can be designated by an identifier (e.g., aport in a header) in the data packet.

At block 614, the second device verifies that the payload was processedby the application. In one embodiment, the application can send amessage indicating that the payload was processed. The application caninclude a link to a library function for verifying the processing, wherethe library function can be part of the operating system. An IDS daemonor other communication management process can receives the message fromthe application.

At block 616, the second device communicates, to the first device, asecond acknowledgment verifying that the payload was processed by theapplication. The second acknowledgment can be sent in a similar manneras the first acknowledgment.

During the processes described in either FIG. 5 or FIG. 6, any number ofother communication processes may be occurring simultaneously, withvarious memory buffers or other systems for managing the communications.As such, certain embodiments may include a memory stack comprising anynumber of data packets, with an application process accepting one ormore data packets at a time, and returning to the stack after thepreviously retrieved data packets are disposed of by the process. Anyaspect of such a process, such as an application retrieving a datapacket, may be used as a trigger to create an acknowledgement that aprevious data packet has been disposed of Additionally, a single devicemay simultaneously be performing both sending and receiving processes,so that a device may be communicating a data packet and expecting anapplication-level acknowledgement to the data packet, while at the sametime sending an application-level acknowledgement. Further, theseprocesses may be occurring with more than two devices at a time, suchthat a single device may be communicating application-levelacknowledgement to multiple devices while at the same time receivingapplication-level acknowledgements from multiple devices different fromthe multiple devices it is communicating to.

III. Protocol Stack

FIG. 7 shows a protocol stack 700 for communicating data according toembodiments of the present invention. In various embodiments, theprotocol stack 700 may be implemented as part of first device 300 ofFIG. 3, as mobile device 900 of FIG. 9, or as part of any other devicedescribed herein. In certain embodiments, the protocol stack 700 may beused to manage retransmission priority either in whole or in part.Various modules in protocol stack 700 can be omitted, or other modulesadded. The software modules can be run on a same processor or differentprocessors. Although only a few communication protocols are listed,numerous wireless protocols can be used. For example, Bluetoothprotocols can include Basic Rate (BR), Enhanced Data Rate (EDR), and LowEnergy (LE) options. Bluetooth BR/EDR is also referred to as ClassicBluetooth.

The communication of data from a device (e.g., mobile device 115,companion device 120, first device 300, or second device 350) can occurthrough various protocols (e.g., 802.11 protocols, Bluetooth protocols,and near field communication (NFC) protocols). To determine whichprotocol to use, a device can include a link manager for determiningwhich protocol to use for a particular application, and thus whichdriver path data should be sent. A lower level link layer can alsoperform selections of a particular protocol to use. Further, a usertunnel (UTUN) controller can coordinate a plurality of virtualconnections with various client applications to communicate over acommon socket connection with another device (e.g., mobile device 115communicating with companion device 120).

In some embodiments, a client application 705 on the device (e.g.,mobile device 115) can request data to be sent to another device (e.g.,companion device 120). The request can specify the other device via anysuitable identifier, e.g., an account name, an IP address, a MACaddress, etc. The request can be before or after the device determinesthat the other device is within communication, e.g., as determined byinitial signaling, such as a handshake. The data (e.g., in a message ora stream) can be sent any suitable application layer protocol, such asHTTP, RTP, SMTP, MGCP, etc. The other device can be any device,including another device of the user. The request can made be inresponse to an action by the user, an internal event (e.g., based ontime or other criteria) that may be in a same or other application(e.g., a calendar app), or an external event (e.g., in response to amessage from another device). An example of an event is a syncing event.

Before sending data, client application 705 can submit an open socketrequest (e.g., in a streaming example). The socket request can useinformation from an identity services (IDS) framework 715, which canprovide an address (or other type of ID) for the other device. Forexample, client application 705 can know account information for thesecond device (e.g., account information of a different or same user),and IDS framework 715 can store a list of device IDs for a particularaccount. IDS framework 715 can be in communication with identitymanagement infrastructure 105 to obtain the list. Thus, IDS framework715 can store or otherwise obtain device IDs (e.g., addresses) for alldevices that a user has registered with ID infrastructure 105. Forexample, IDS framework 715 can request via an IDS daemon to IDinfrastructure 105 to obtain the device IDs. In one implementation, thesocket request can be made to kernel 710.

In a messaging example, the request to send data can go to IDS framework715 to obtain a device ID, which can be sent to message a messagecontroller 718 and a user tunnel (UTUN controller 720. UTUN controllercan establish a mapping between the device ID and an IP address (e.g., avirtual IP address) when the device ID is not an IP address. A socketcan be created between message controller 718 (which assigns a device IDto the socket) and kernel 710 (which can assigns an address to thesocket, such as a virtual IP address). UTUN controller can be used tocreate the socket connection between message controller 718 and kernel710. In this manner, the send-date request from client application 705does not need to include a device ID, but can specify an account, whichcan then be cross-referenced by IDS framework 715 with known devices ofthe account and their capabilities (e.g., if the request requirescertain capabilities). Given that a device ID can be obtained, a pairingdoes not need to occur prior to creating the socket.

In various embodiments, IDS framework 715 can receive a particularport/service at the other device from client application 705, determinethe port/service based on information obtained from ID infrastructure105, or determine the port/service from a token sent in the request. IDSframework 715 can then communicate a device ID and other headerinformation to message controller 718 and/or UTUN controller 720. IDSframework 715 and UTUN controller 720 can communicate via cross processcommunication (XPC). UTUN controller 720 can be part of an IDS daemon,and can receive a device ID from ID infrastructure 105.

As mentioned above, UTUN controller 720 can create a virtual addressthat corresponds to the actual device address, where the virtual addresscan be used to create a virtual socket. A virtual socket can also becreated using any device ID (e.g., an actual address of a device orother ID). As an example, a socket can be created for communicationbetween client application 705 and kernel 710 (e.g., in a streamingcontext), where kernel 710 can have various sockets open with variousclient applications. Kernel 710 can have a single connection to UTUNcontroller 720 for the other device and multiplex (mux) the data fromvarious client applications into the single connection. Instead or inaddition, UTUN controller 720 can also perform the muxing, e.g., ifmultiple socket exist between kernel 710 and UTUN controller 720 forvarious client applications to the other device. Incoming data can bedemultiplexed (demuxed) for sending to the destination clientapplication.

As another example, a socket can be created between kernel 710 andmessage controller 718 (e.g., in a messaging context), where a socketcan be created for each destination device, with different sockets to asame device potentially having different priorities. Thus, a particularvirtual socket can be associated with a particular device and aparticular priority (e.g., high and low). Message controller 718 canhave various connections to various client applications. Thus, messagecontroller 718 can provide mux/demux capabilities.

UTUN controller can create a primary socket with the other device. WhenUTUN controller 720 receives data using a virtual connection associatedwith the second device, it can then map the virtual connection to theprimary socket for communicating with the other device. All data for theother device can then be sent out through the primary socket. Thevirtual address for a virtual socket can be passed back to clientapplication 715, e.g., in the stream context. In one embodiment, avirtual socket involving kernel 710 is a TCP socket. The virtual addresscan have a same format as a regular address, e.g., an IPv6 address. Amux module can include any combination of kernel 710, message controller718, and UTUN controller 720.

When client application sends data, client application 705 can use thevirtual socket to send data to kernel 710. For example, the data can besent using TCP via the virtual socket. Kernel 710 can implement an UTUNinterface for communicating with UTUN controller 720. Kernel 710 wouldpass the data (e.g., with a TCP header) and the virtual socketidentifying the virtual address to UTUN controller 720, which would thenuse the virtual address to resolve the device address for determiningthe device socket.

When sending to the data over the device socket, a link manager 725 candetermine which link to use. A link can be a particular combination of awireless interface protocol (e.g., Bluetooth or Wi-Fi), a transportprotocol (e.g., TCP, UDP, etc.), and a destination device. In thismanner, UTUN controller 720 does not need to know how the data is beingsent, but instead can simply send the data to link manager 725.

In various embodiments, the determination by link manger 725 can be madeper data packet, per set of data packets, per device socket, and maychange from one data packet to another. Link manager 725 may then selecta link for sending the data. In the example shown, a Wi-Fi link 730provides software drivers for communicating with one or more Wi-Fiprotocols, and BLTE link 735 provides software drivers for communicatingwith Blutooth LE. Wi-Fi link 730 is in communication with Wi-Fi hardware760, and BLTE link 735 is in communication with BTLE hardware 755. Wi-Filink 730 can be used for various Wi-Fi protocols, such as infra-Wi-Fi(infrastructure Wi-Fi). In one embodiment, link manager 725 can try alllinks to determine whether any of the links can contact the otherdevice, and then use a connected link with a highest predetermined rankor dynamic rank.

Hardware 750-760 can be in communication with links assigned to variousdevices. For example, links 730, 735, and 740 can be assigned forcommunication with a second device. And, other links that are assignedfor communication with a third device can also be in communication withhardware 750-760. When a particular hardware receives data, software canidentify a particular sending device and then determine thecorresponding link, e.g., using header information to determine the linkcorresponding to the sending device and transport protocol.

In some embodiments, a combined link 740 can include an interface 744for communicating with link manager 724 and a selector 748 that selectsa particular protocol to use. The protocols can be the same or differentthan that available to link manager 725. Selector 748 can performsimilar functions as link manager 725 in that a particular link isselected. However, link manager 725 and selector 748 can use differentcriteria for determining which link to use. For example, link manager725 can determine to use combined link 740, and selector 748 can thendetermine that BTLE hardware 755 is to be used. The hardware can becontained on a same or separate chips.

One or more protocols can be only available via combined link 740, suchas classic Bluetooth hardware 750. Link manager 725 and selector 748 canuse various criteria for determining which link to use, such as powerusage of a link, speed of a link (e.g., real-time data rate), and signalstrength of a link. A goal of the optimization for selecting a link canbe to provide a minimal data rate at a lowest possible energy.

IV. Mobile Device

FIG. 8 is a block diagram of a portable electronic device or mobiledevice 800 according to an embodiment of the invention. Mobile device800 generally includes computer-readable medium 802, a processing system804, an Input/Output (I/O) subsystem 806, wireless circuitry 808, andaudio circuitry 810 including speaker 850 and microphone 852. Thesecomponents may be coupled by one or more communication buses or signallines 803. Device 800 can be any portable electronic device, including ahandheld computer, a tablet computer, a mobile phone, laptop computer,tablet device, media player, personal digital assistant (PDA), a keyfob, a car key, an access card, a multi-function device, a mobile phone,a portable gaming device, or the like, including a combination of two ormore of these items. In various embodiments, first device 300 or seconddevice 350 or any other device, server, access point, network element orother computing device or element may be implemented in whole or in partusing the elements of FIG. 8.

It should be apparent that the architecture shown in FIG. 8 is only oneexample of an architecture for mobile device 800, and that device 800can have more or fewer components than shown, or a differentconfiguration of components. The various components shown in FIG. 8 canbe implemented in hardware, software, or a combination of both hardwareand software, including one or more signal processing and/or applicationspecific integrated circuits.

Wireless circuitry 808 is used to send and receive information over awireless link or network to one or more other devices' conventionalcircuitry such as an antenna system, an RF transceiver, one or moreamplifiers, a tuner, one or more oscillators, a digital signalprocessor, a CODEC chipset, memory, etc. In some embodiments, wirelesscircuitry 808 is capable of establishing and maintaining communicationswith other devices using one or more communication protocols, includingtime division multiple access (TDMA), code division multiple access(CDMA), global system for mobile communications (GSM), Enhanced Data GSMEnvironment (EDGE), wideband code division multiple access (W-CDMA),Long Term Evolution (LTE), LTE-Advanced, Wi-Fi (such as IEEE 802.11a,IEEE 802.11b, IEEE 802.11g and/or IEEE 802.11n), Bluetooth, Wi-MAX,voice over Internet Protocol (VoIP), near field communication protocol(NFC), a protocol for email, instant messaging, and/or a short messageservice (SMS), or any other suitable communication protocol, includingcommunication protocols not yet developed as of the filing date of thisdocument. A mobile device can include wireless circuitry that cancommunicate over several different types of wireless networks dependingon the range required for the communication. For example, a short-rangewireless transceiver (e.g., Bluetooth), a medium-range wirelesstransceiver (e.g., Wi-Fi), and/or a long range wireless transceiver(e.g., GSM/GPRS, UMTS, CDMA2000 1x/EV-DO and LTE/LTE-Advanced) can beused depending on the type of communication or the range of thecommunication.

Wireless circuitry 808 is coupled to processing system 804 viaperipherals interface 816. Interface 816 can include conventionalcomponents for establishing and maintaining communication betweenperipherals and processing system 804. Voice and data informationreceived by wireless circuitry 808 (e.g., in speech recognition or voicecommand applications) is sent to one or more processors 818 viaperipherals interface 816. One or more processors 818 are configurableto process various data formats for one or more application programs 834stored on medium 802.

Peripherals interface 816 couple the input and output peripherals of thedevice to processor 818 and computer-readable medium 802. One or moreprocessors 818 communicate with computer-readable medium 802 via acontroller 820. Computer-readable medium 802 can be any device or mediumthat can store code and/or data for use by one or more processors 818.Medium 802 can include a memory hierarchy, including cache, main memoryand secondary memory. The memory hierarchy can be implemented using anycombination of RAM (e.g., SRAM, DRAM, DDRAM), ROM, FLASH, magneticand/or optical storage devices, such as disk drives, magnetic tape, CDs(compact disks) and DVDs (digital video discs). In some embodiments,peripherals interface 816, one or more processors 818, and memorycontroller 820 can be implemented on a single chip, such as processingsystem 804. In some other embodiments, they can be implemented onseparate chips.

Mobile device 800 also includes a power system 842 for powering thevarious hardware components. Power system 842 can include a powermanagement system, one or more power sources (e.g., battery, alternatingcurrent (AC)), a recharging system, a power failure detection circuit, apower converter or inverter, a power status indicator (e.g., a lightemitting diode (LED)) and any other components typically associated withthe generation, management and distribution of power in mobile devices.

In some embodiments, mobile device 800 includes a camera 844. In someembodiments, mobile device 800 includes sensors 846. Sensors can includeaccelerometers, compass, gyrometer, pressure sensors, audio sensors,light sensors, barometers, and the like. Sensors 846 can be used tosense location aspects, such as auditory or light signatures of alocation.

In some embodiments, mobile device 800 can include a GPS receiver,sometimes referred to as a GPS unit 848. A mobile device can use asatellite navigation system, such as the Global Positioning System(GPS), to obtain position information, timing information, altitude, orother navigation information. During operation, the GPS unit can receivesignals from GPS satellites orbiting the Earth. The GPS unit analyzesthe signals to make a transit time and distance estimation. The GPS unitcan determine the current position (current location) of the mobiledevice. Based on these estimations, the mobile device can determine alocation fix, altitude, and/or current speed. A location fix can begeographical coordinates such as latitudinal and longitudinalinformation.

One or more processors 818 run various software components stored inmedium 802 to perform various functions for device 800. In someembodiments, the software components include an operating system 822, acommunication module (or set of instructions) 824, a location module (orset of instructions) 826, and other applications (or set ofinstructions) 834, such as a car locator app and a navigation app.

Operating system 822 can be any suitable operating system, includingiOS, Mac OS, Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or an embeddedoperating system such as VxWorks. The operating system can includevarious procedures, sets of instructions, software components and/ordrivers for controlling and managing general system tasks (e.g., memorymanagement, storage device control, power management, etc.) andfacilitates communication between various hardware and softwarecomponents.

Communication module 824 facilitates communication with other devicesover one or more external ports 836 or via wireless circuitry 808 andincludes various software components for handling data received fromwireless circuitry 808 and/or external port 836. External port 836(e.g., USB, FireWire, Lightning connector, 30-pin connector, etc.) isadapted for coupling directly to other devices or indirectly over anetwork (e.g., the Internet, wireless LAN, etc.).

Location/motion module 826 can assist in determining the currentposition (e.g., coordinates or other geographic location identifier) andmotion of mobile device 800. Modern positioning systems includesatellite based positioning systems, such as Global Positioning System(GPS), cellular network positioning based on “cell IDs,” and Wi-Fipositioning technology based on a Wi-Fi networks. Typically, GPS is themost accurate, but often consumes more power than the other positioningsystems. GPS also relies on the visibility of multiple satellites todetermine a position estimate, which may not be visible (or have weaksignals) indoors or in “urban canyons.” In some embodiments,location/motion module 826 receives data from GPS unit 848 and analyzesthe signals to determine the current position of the mobile device. Insome embodiments, location/motion module 826 can determine a currentlocation using Wi-Fi or cellular location technology. For example, thelocation of the mobile device can be estimated using knowledge of nearbycell sites and/or Wi-Fi access points with knowledge also of theirlocations. Information identifying the Wi-Fi or cellular transmitter isreceived at wireless circuitry 808 and is passed to location/motionmodule 826. In some embodiments, the location module receives the one ormore transmitter IDs. In some embodiments, a sequence of transmitter IDscan be compared with a reference database (e.g., Cell ID database, Wi-Fireference database) that maps or correlates the transmitter IDs toposition coordinates of corresponding transmitters, and computesestimated position coordinates for mobile device 800 based at least inpart on the position coordinates of the corresponding transmitters.Regardless of the specific location technology used, location/motionmodule 826 receives information from which a location fix can bederived, interprets that information, and returns location information,such as geographic coordinates, latitude/longitude, or other locationfix data.

The one or more applications 834 on the mobile device can include anyapplications installed on the device 800, including without limitation,a browser, address book, contact list, email, instant messaging, wordprocessing, keyboard emulation, widgets, JAVA-enabled applications,encryption, digital rights management, voice recognition, voicereplication, a music player (which plays back recorded music stored inone or more files, such as MP3 or AAC files), etc. The one or moreapplications 834 can also include a specific app for finding a parkedcar, a maps application, or any other suitable application.

There may be other modules or sets of instructions (not shown), such asa graphics module, a time module, etc. For example, the graphics modulecan include various conventional software components for rendering,animating and displaying graphical objects (including without limitationtext, web pages, icons, digital images, animations and the like) on adisplay surface. In another example, a timer module can be a softwaretimer. The timer module can also be implemented in hardware. The timemodule can maintain various timers for any number of events.

The I/O subsystem 806 can be coupled to a display system (not shown),which can be a touch-sensitive display. The display displays visualoutput to the user in a GUI. The visual output can include text,graphics, video, and any combination thereof. Some or all of the visualoutput can correspond to user-interface objects. A display can use LED(light emitting diode), LCD (liquid crystal display) technology, or LPD(light emitting polymer display) technology, although other displaytechnologies can be used in other embodiments.

In some embodiments, I/O subsystem 806 can include a display and userinput devices such as a keyboard, mouse, and/or trackpad. In someembodiments, I/O subsystem 806 can include a touch-sensitive display. Atouch-sensitive display can also accept input from the user based onhaptic and/or tactile contact. In some embodiments, a touch-sensitivedisplay forms a touch-sensitive surface that accepts user input. Thetouch-sensitive display/surface (along with any associated modulesand/or sets of instructions in medium 802) detects contact (and anymovement or release of the contact) on the touch-sensitive display andconverts the detected contact into interaction with user-interfaceobjects, such as one or more soft keys, that are displayed on the touchscreen when the contact occurs. In some embodiments, a point of contactbetween the touch-sensitive display and the user corresponds to one ormore digits of the user. The user can make contact with thetouch-sensitive display using any suitable object or appendage, such asa stylus, pen, finger, and so forth. A touch-sensitive display surfacecan detect contact and any movement or release thereof using anysuitable touch sensitivity technologies, including capacitive,resistive, infrared, and surface acoustic wave technologies, as well asother proximity sensor arrays or other elements for determining one ormore points of contact with the touch-sensitive display.

Further, the I/O subsystem can be coupled to one or more other physicalcontrol devices (not shown), such as pushbuttons, keys, switches, rockerbuttons, dials, slider switches, sticks, LEDs, etc., for controlling orperforming various functions, such as power control, speaker volumecontrol, ring tone loudness, keyboard input, scrolling, hold, menu,screen lock, clearing and ending communications and the like. In someembodiments, in addition to the touch screen, device 800 can include atouchpad (not shown) for activating or deactivating particularfunctions. In some embodiments, the touchpad is a touch-sensitive areaof the device that, unlike the touch screen, does not display visualoutput. The touchpad can be a touch-sensitive surface that is separatefrom the touch-sensitive display or an extension of the touch-sensitivesurface formed by the touch-sensitive display.

Advantages to certain embodiments of the invention include automaticallymarking a parking location when it is determined that a car is in aparked state. This can be done without prompting by the user andtherefore the user does not have to remember to manually mark a parkinglocation. This improves the user experience and is more convenient forthe user.

Further advantages to certain embodiments of the invention includeenabling parking location marking in weak location signal scenarios.Some embodiments of the invention permit marking a car's parkinglocation without using transponders in parking areas (e.g., transpondernear parking spots) to transmit a unique identifier which can be used tolocate a parking spot.

In some embodiments, some or all of the operations described herein canbe performed using an application executing on the user's mobile device.Circuits, logic modules, processors, and/or other components may beconfigured to perform various operations described herein. Those skilledin the art will appreciate that, depending on implementation, suchconfiguration can be accomplished through design, setup,interconnection, and/or programming of the particular components andthat, again depending on implementation, a configured component might ormight not be reconfigurable for a different operation. For example, aprogrammable processor can be configured by providing suitableexecutable code; a dedicated logic circuit can be configured by suitablyconnecting logic gates and other circuit elements; and so on.

Computer programs incorporating various features of the presentinvention may be encoded on various computer readable storage media;suitable media include magnetic disk or tape, optical storage media suchas compact disk (CD) or DVD (digital versatile disk), flash memory, andthe like. Computer readable storage media encoded with the program codemay be packaged with a compatible device or provided separately fromother devices. Any such computer readable medium may reside on or withina single computer product (e.g. a hard drive, a CD, or an entirecomputer system), and may be present on or within different computerproducts within a system or network. In addition program code may beencoded and transmitted via wired optical, and/or wireless networksconforming to a variety of protocols, including the Internet, therebyallowing distribution, e.g., via Internet download.

Although the invention has been described with respect to specificembodiments, it will be appreciated that the invention is intended tocover all modifications and equivalents within the scope of thefollowing claims.

1. A method comprising: at a first device comprising wireless circuitry,a memory, and a processor coupled to the memory and the wirelesscircuitry: communicating, via the wireless circuitry, with an identityservices server to receive a second identifier associated with a seconddevice; communicating a data packet to the second device via thewireless circuitry, the data packet comprising the second identifier anda payload; receiving from a communication management process of thesecond device, a first acknowledgement indicating that the data packetwas received at the second device; and receiving from the communicationmanagement process of the second device, a second acknowledgementindicating that the payload has been processed by a second applicationoperating on the second device.
 2. The method of claim 1, whereincommunicating the data packet to the second device comprises:communicating the payload from a first application of the first deviceto a communication management process of the first device.
 3. The methodof claim 1, wherein communicating the data packet to the second devicefurther comprises: communicating the data packet from the first identityservices daemon of the first device to the identity services server forrelay to the second device.
 4. The method of claim 1, whereincommunicating with the identity services server to receive the secondidentifier comprises: communicating with the identity services servervia a first identity services daemon of the first device.
 5. The methodof claim 1, wherein the communication management process of the firstdevice comprises the first identity services daemon of the first device.6. The method of claim 1, wherein receiving from the communicationmanagement process of the second device, the first acknowledgementindicating that the data packet was received at the second devicecomprises: receiving the first acknowledgement from the identityservices server.
 7. The method of claim 1, further comprising: at thefirst device: communicating a second data packet to the second device inresponse to receipt of the second acknowledgement.
 8. The method ofclaim 1, further comprising: at a first device: determining that thesecond acknowledgement has not been received within a predeterminedamount of time; and delaying transmission of a third data packet inresponse to the determination that the second acknowledgement has notbeen received within the predetermined amount of time.
 9. The method ofclaim 1, wherein the second acknowledgement is received from a secondidentity services daemon of the second device.
 10. The method of claim1, further comprising: communicating, by a push notification daemon ofthe first device via the wireless circuitry, with a push notificationserver to identify a connection between the first device and the seconddevice.
 11. The method of claim 1, wherein the first acknowledgementcomprises a push acknowledgement from a second push notification daemonof the second device.
 12. The method of claim 1, wherein the firstacknowledgement and the second acknowledgement are received as part of acombined acknowledgement communication, the combined acknowledgementcommunication comprising a flag setting indicating that the combinedacknowledgement communication comprises the first acknowledgement andthe second acknowledgement.
 13. A first device comprising: wirelesscircuitry; a memory; and at least one processor coupled to the memoryand the wireless circuitry, the at least one processor configured to:communicate, via the wireless circuitry, with an identity servicesserver to receive a second identifier associated with a second device;communicate a data packet to the second device via the wirelesscircuitry, the data packet comprising the second identifier and apayload; receive from a communication management process of the seconddevice, a first acknowledgement indicating that the data packet wasreceived at the second device; and receive from the communicationmanagement process of the second device, a second acknowledgementindicating that the payload has been processed by a second applicationoperating on the second device.
 14. The first device of claim 13,wherein the at least one processor is further configured to: determinethat the second acknowledgement has not been received within apredetermined amount of time; and delay transmission of a third datapacket in response to the determination that the second acknowledgementhas not been received within the predetermined amount of time.
 15. Thefirst device of claim 13, wherein the at least one processor is furtherconfigured to: communicate a second data packet to the second device inresponse to receipt of the second acknowledgement.
 16. The first deviceof claim 13, wherein the wireless circuitry comprises a near fieldcommunication interface; and wherein communicating the data packet tothe second device is performed using the near field communicationinterface as part of a peer to peer connection between the first deviceand the second device.
 17. A computer product comprising anon-transitory computer readable medium storing a plurality ofinstructions that, when executed, control a first device comprisingwireless circuitry, a memory, and a processor coupled to the memory andthe wireless circuitry to perform a method of implementingapplication-level acknowledgements, the instructions comprising:communicating, via the wireless circuitry, with an identity servicesserver to receive a second identifier associated with a second device;communicating a data packet to the second device via the wirelesscircuitry, the data packet comprising the second identifier and apayload; receiving from a communication management process of the seconddevice, a first acknowledgement indicating that the data packet wasreceived at the second device; and receiving from the communicationmanagement process of the second device, a second acknowledgementindicating that the payload has been processed by a second applicationoperating on the second device.
 18. The computer product of claim 17,wherein the instructions further comprise: receiving, by a communicationmanagement process of the first device, a second data packet comprisinga second payload and a first identifier associated with the firstdevice; communicating a third acknowledgement to the second device usingthe second identifier, the third acknowledgement verifying receipt ofthe second data packet; processing the payload using an application ofthe first device; verifying that the second payload was processed by theapplication; and communicating from the first device to the seconddevice, a fourth acknowledgment verifying that the second payload wasprocessed by the application of the first device.
 19. The computerproduct of claim 17, wherein the instructions further comprise:determining that the second acknowledgement has not been received withina predetermined amount of time; and delaying transmission of a thirddata packet in response to the determination that the secondacknowledgement has not been received within the predetermined amount oftime.
 20. The computer product of claim 17, wherein the instructionsfurther comprise: communicating a second data packet to the seconddevice in response to receipt of the second acknowledgement. 21-40.(canceled)